ci(deploy): still probe chat when the rollout gate fails - #1961

What

The chat probe runs when the rollout gate fails, not only when every step before it succeeded.

• Verify rollout of the deployed workloads gets id: rollout.
• Verify the new backend serves chat gets if: ${{ success() || steps.rollout.outcome == 'failure' }}.

Why

Measured on the deploy that hung (Deploy Dev run 36313468431, image 4e60f240, 2026-09-27): kubectl rollout status "$d" --timeout=8m fails → the step exit 1s at line 227 inside itself → the job stops there → the chat-probe step at line 238 is skipped. The only two if: always() steps in the job are the notice and the outcome report below it.

So the operator gets backend did not become ready within 8m and nothing else, while the step that does not run carries the one line that would explain it:

::error title=Chat unavailable on the new backend::$POD has pg/status=$STATUS and pg/messages=$ROUTE (401 means mounted, 404 unmounted)

That 401/404 is the discriminator between readiness is lying about a pod that is serving and the pod is genuinely broken — and the first is the exact shape of the #1901/#1958 family (Sentry wrapping the layer handle made the mount probe answer false, so /ready refused a pod whose /api/pg/messages was mounted). A stuck rollout arrives with its own cause attached instead of a generic one, and the diagnosis that cost time that night is available from the job log.

Both facts re-read from the workflow, not inferred: the exit 1 is at line 227 of the rollout step; the probe at line 238 has no if:; the if: always() at line 267 belongs to the notice step.

How, and why not always()

if: ${{ success() || steps.rollout.outcome == 'failure' }} — verified from the workflow, not taken on trust.

Deliberately not always() / !cancelled(). Those also run the probe when an earlier step failed — image push, Helm upgrade, GKE credentials — where the cluster may be unreachable or unchanged and the newest backend pod is the old one. The probe would then print Chat unavailable on the new backend for a reason that has nothing to do with chat, i.e. it would trade a generic-but-true error for a specific-but-false one. Condition on the step that actually matters.

Safety

This cannot turn a passing deploy red:

The added case is output on a job that has already failed, so its exit code changes nothing; the worst case is the 6×10s exec retry loop on an already-red job. If the stuck pod is the newest one and cannot exec at all, the loop still ends in the named error rather than a false "serves chat".

Verification

• YAML.load_file parses the file; both steps read back with the expected id / if.
• No test in the repo consumes this workflow (grepped).
• Not exercised end-to-end here — that needs a failing rollout in the cluster. The semantic relied on is explicit: the expression contains a status check function, so the implicit success() gate does not apply and the disjunction governs.

Companion row: TASK-173. Found while gating #1958 (sprint-review's observation, verified against the workflow here).